Linus Torvalds Posts on comp.os.minix Searched Groups for group:comp.os.minix author:Linus author:Torvalds. Results 1 - 44 of 44. ============================================================ From: torvalds@cc.helsinki.fi Newsgroups: comp.os.minix Subject: gcc on minix-386 doesn't optimize? Message-ID: <1991Mar29.151930.5767@cc.helsinki.fi> Date: 29 Mar 91 15:19:30 GMT Organization: University of Helsinki Lines: 22 Hello everybody, I've had minix for a week now, and have upgraded to 386-minix (nice), and duly downloaded gcc for minix. Yes, it works - but ... optimizing isn't working, giving an error message of "floating point stack exceeded" or something. Is this normal? I had problems with the crcs, so I'm not actually sure I've gotten it right (pretty sure though), but I'm somewhat surprised that gcc would use floating point in normal optimizations when the program under compilation certainly doesn't. I've downloaded the sources (2.9Mb for just gcc, not gas etc), but due to a rather small HD I've been unable to untar them completely, so I cannot recompile or anything. I could get one of the floating point packages floating around, if that is the problem, but my understanding is that the current binary cannot take advantage of them anyway. Could somebody please tell me what's the story behind the gcc floating point? advTHANKSance, Linus Torvalds torvalds@cc.helsinki.fi PS. No it's not a big problem, even without optimization I get around 7000 dhrystones, I'm just wondering. And yes - I'll get a bigger HD as soon as my somewhat strained economy can make it 8-). ======================================= ======================================= From: torvalds@cc.helsinki.fi Newsgroups: comp.os.minix Subject: Re: PS and Minix-386. Message-ID: <1991Apr1.123039.5786@cc.helsinki.fi> Date: 1 Apr 91 12:30:39 GMT References: <7210@munnari.oz.au> Organization: University of Helsinki Lines: 46 In article , kemp@convex.com (Phil Kemp) writes: > In <7210@munnari.oz.au> bevan@ecr.mu.oz.au (Bevan Anderson) writes: > >>I recompiled ps.c with bcc -3 so to give me a 32 bit >>binary. Now when I execute ps (as root) I get: >>memory fault: core dumped. >>This happens after ps puts up the top line of the output (TTY LINE etc) >>I am doing a ps -U but that gets the same problem. > > I too have had similar problems with the various versions of ps with > the 386 Minix kernel. Maybe someone could post a version of ps.c which > does in fact work with Bruce's 386 Minix... > > I know I would sure appreciate it. > > Thanks. > PK > -- > Phil Kemp > CONVEX Computer of Canada Ltd. > Voice:(403)-233-2815 > UUCP:kemp@convex.com RTFSC (Read the F**ing Source Code :-) - It is heavily commented and the solution should be obvious (take that with a grain of salt, it certainly stumped me for a while :-). Simply change the 4 define-lines at the start (well, I'd guess about line 40) that read #define kernel "/usr/src/kernel/kernel" #define mm "/usr/src/mm/mm" #define fs "/usr/src/fs/fs" #define init "/usr/src/tools/init" to where-ever you have them now (/etc/system/kernel,fs,init,mm if you did as the tutor that is floating around said) NOTE! I wrote this from memory - this is certainly not exactly how the defines look (and I'm not certain that there is a define for init, I think it never gets used). It should be no problem finding them though - there should be nothing like it elsewhere in ps.c. It is inside a #if by the way. Cdiffs might be a good idea, but I don't have access to my minix-box right now. Doing them manually wasn't any problem. Linus Torvalds torvalds@cc.helsinki.fi =============================== =============================== From: torvalds@cc.helsinki.fi Newsgroups: comp.os.minix Subject: Re: 386 goodies sought Message-ID: <1991Apr8.125827.5888@cc.helsinki.fi> Date: 8 Apr 91 12:58:27 GMT References: <1991Apr7.230652.3535@cunixf.cc.columbia.edu> Organization: University of Helsinki Lines: 47 In article <1991Apr7.230652.3535@cunixf.cc.columbia.edu>, rt2@cunixb.cc.columbia.edu (Rens Troost) writes: > > I've just gone through upgrading to 386 (thanks, Bruce) and now am looking > for some new stuff -- if I remember correctly someone had a set of diffs for > emacs. What is the status of this? > > Also, has anybody gotten bash working for minix? gdb? (this latter must be > a dream...) > > -Rens > rt2@cunixb.cc.columbia.edu > rens@gnu.ai.mit.edu I'm rather new to 386-Minix myself, but have tried porting some stuff and have a few comments: 1) Get gcc! Without this your porting will be much more difficult. You don't even need to do anything, it's been ported already, and binaries can be found on plains. Great! 2) I dont know about others, but with 386-minix and gcc the system is close enough to "real" unix that most gnu-programs seem to work without any major changes. I tried getting a "minix-ported" bash, and had no end of troubles. Get the real unmodified gnu-sources. 3) gnu tar, gawk and bison are easy - get them, make some small changes, and you're up and away. Took me a couple of hours to port them, and I was totally new to the game. 4) Bash is hell :-) It uses ioctl etc that at least vanilla-minix386 doesn't care about (anybody hacked the kernel?), but it's doable. I ported it yesterday, sort of (you'll need bison), haven't had time to test it out yet. I have problems with readline, but I think it's a minor problem. It hasn't bombed on me yet though. 5) If you want emacs, I think there are patches on plains, but I'm not sure. If uemacs will do (it does for me), get that - it takes no porting at all (well very little - change some defines in estruct.h, maybe some very minor other changes). Be sure to get 3.10 (latest version that I'm aware of), it has &kbg, which allows you to make appropriate macros for the cursor keys - no need to change the sources. There is a bug in bind.c (I think),but there are bug-fixes available that seem to clear it up (if you want it, mail me). Happy porting, Linus Linus Torvalds torvalds@cc.helsinki.fi ========================== ========================== From: torvalds@cc.helsinki.fi Newsgroups: comp.os.minix Subject: Anyone in need of bash? (minix-386, maybe ST) Message-ID: <1991Apr13.181744.5973@cc.helsinki.fi> Date: 13 Apr 91 18:17:44 GMT Organization: University of Helsinki Lines: 18 I've recently ported bash to minix-386 (nice, but takes about 300kB of RAM). It's been "tested" by me using it all the time (good editing and history - couldn't live without it any more), but I won't make any guarantees. If anybody is interested in cdiffs against bash-1.05, please mail me (I'll post if there is enough interest). The port definitely needs GCC, and 386-minix. ST-minix will probably work as well (I've sent it to one ST-minixer), after changeing a #define LITTLE_ENDIAN to BIG_ENDIAN. If the port already has been done by someone else - just ignore this message. Linus Torvalds torvalds@cc.helsinki.fi PS. I've hacked the kernel to accept gcc-compiled programs directly without going through gcc2minix, but I haven't tested it very much yet (bash works though, so most things probably will). Changes are trivial, mail me if interested. (And yes - it accepts old minix format too - you don't have to recompile everything :-) ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Gcc-1.40 and a posix-question Keywords: gcc, posix Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI> Date: 3 Jul 91 10:00:50 GMT Organization: University of Helsinki Lines: 28 Hello netlanders, Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice. As an aside for all using gcc on minix - the new version (1.40) has been out for some weeks, and I decided to test what needed to be done to get it working on minix (1.37.1, which is the version you can get from plains is nice, but 1.40 is better :-). To my surpice, the answer turned out to be - NOTHING! Gcc-1.40 compiles as-is on minix386 (with old gcc-1.37.1), with no need to change source files (I changed the Makefile and some paths, but that's it!). As default this results in a compiler that uses floating point insns, but if you'd rather not, changing 'toplev.c' to define DEFAULT_TARGET from 1 to 0 (this is from memory - I'm not at my minix-box) will handle that too. Don't make the libs, use the old gnulib&libc.a. I have successfully compiled 1.40 with itself, and everything works fine (I got the newest versions of gas and binutils at the same time, as I've heard of bugs with older versions of ld.c). Makefile needs some chmem's (and gcc2minix if you're still using it). Linus Torvalds torvalds@kruuna.helsinki.fi PS. Could someone please try to finger me from overseas, as I've installed a "changing .plan" (made by your's truly), and I'm not certain it works from outside? It should report a new .plan every time. From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Gcc-1.40 and a posix-question Keywords: gcc, posix Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI> Date: 3 Jul 91 10:00:50 GMT Organization: University of Helsinki Lines: 28 Hello netlanders, Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice. As an aside for all using gcc on minix - the new version (1.40) has been out for some weeks, and I decided to test what needed to be done to get it working on minix (1.37.1, which is the version you can get from plains is nice, but 1.40 is better :-). To my surpice, the answer turned out to be - NOTHING! Gcc-1.40 compiles as-is on minix386 (with old gcc-1.37.1), with no need to change source files (I changed the Makefile and some paths, but that's it!). As default this results in a compiler that uses floating point insns, but if you'd rather not, changing 'toplev.c' to define DEFAULT_TARGET from 1 to 0 (this is from memory - I'm not at my minix-box) will handle that too. Don't make the libs, use the old gnulib&libc.a. I have successfully compiled 1.40 with itself, and everything works fine (I got the newest versions of gas and binutils at the same time, as I've heard of bugs with older versions of ld.c). Makefile needs some chmem's (and gcc2minix if you're still using it). Linus Torvalds torvalds@kruuna.helsinki.fi PS. Could someone please try to finger me from overseas, as I've installed a "changing .plan" (made by your's truly), and I'm not certain it works from outside? It should report a new .plan every time. ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: gcc 1.40 for Minix-386 Message-ID: <1991Aug20.121735.19947@klaava.Helsinki.FI> Date: 20 Aug 91 12:17:35 GMT References: <1991Aug19.220059.27322@Informatik.TU-Muenchen.DE> Organization: University of Helsinki Lines: 26 In article <1991Aug19.220059.27322@Informatik.TU-Muenchen.DE> rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) writes: >Someone reported a while ago that compiling gcc 1.40 for Minix-386 would >be straightforward with the running gcc 1.37. I have tried this. >Compiling gcc was not that difficult. But I have a problem now. >cc1 cores on signal 6 when >a) a file with floating point is compiled >b) -O is used. > >Kai Uwe Rommel > Ok. I'm the one that reported porting was easy. Seems I didn't explain enough :-). This is what happens when you either have compiled cc1 without using -msoft-float (the gcc from plains uses soft-float by default, but if you compile cc1-1.40 with itself you must put a -msoft-float in the makefile). The other possibility is that you aren't using the crt0.o that was shipped with the original gcc-1.37.1 by black&tobin (?). It is needed to get the signal handler started. The thing to do is recompile cc1 from scratch while using -msoft-float, or changing DEFAULT_TARGET to 0 in tm.h (and then recompiling cc1). This should fix the problem. Linus (torvalds@kruuna.helsinki.fi) ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: What would you like to see most in minix? Summary: small poll for my new operating system Keywords: 386, preferences Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI> Date: 25 Aug 91 20:57:08 GMT Organization: University of Helsinki Lines: 20 Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things). I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-) Linus (torvalds@kruuna.helsinki.fi) PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(. ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Free minix-like kernel sources for 386-AT Keywords: 386, preliminary version Message-ID: <1991Oct5.054106.4647@klaava.Helsinki.FI> Date: 5 Oct 91 05:41:06 GMT Organization: University of Helsinki Lines: 55 Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on a OS you can try to modify for your needs? Are you finding it frustrating when everything works on minix? No more all- nighters to get a nifty program working? Then this post might be just for you :-) As I mentioned a month(?) ago, I'm working on a free version of a minix-lookalike for AT-386 computers. It has finally reached the stage where it's even usable (though may not be depending on what you want), and I am willing to put out the sources for wider distribution. It is just version 0.02 (+1 (very small) patch already), but I've successfully run bash/gcc/gnu-make/gnu-sed/compress etc under it. Sources for this pet project of mine can be found at nic.funet.fi (128.214.6.100) in the directory /pub/OS/Linux. The directory also contains some README-file and a couple of binaries to work under linux (bash, update and gcc, what more can you ask for :-). Full kernel source is provided, as no minix code has been used. Library sources are only partially free, so that cannot be distributed currently. The system is able to compile "as-is" and has been known to work. Heh. Sources to the binaries (bash and gcc) can be found at the same place in /pub/gnu. ALERT! WARNING! NOTE! These sources still need minix-386 to be compiled (and gcc-1.40, possibly 1.37.1, haven't tested), and you need minix to set it up if you want to run it, so it is not yet a standalone system for those of you without minix. I'm working on it. You also need to be something of a hacker to set it up (?), so for those hoping for an alternative to minix-386, please ignore me. It is currently meant for hackers interested in operating systems and 386's with access to minix. The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If you are still interested, please ftp the README/RELNOTES, and/or mail me for additional info. I can (well, almost) hear you asking yourselves "why?". Hurd will be out in a year (or two, or next month, who knows), and I've already got minix. This is a program for hackers by a hacker. I've enjouyed doing it, and somebody might enjoy looking at it and even modifying it for their own needs. It is still small enough to understand, use and modify, and I'm looking forward to any comments you might have. I'm also interested in hearing from anybody who has written any of the utilities/library functions for minix. If your efforts are freely distributable (under copyright or even public domain), I'd like to hear from you, so I can add them to the system. I'm using Earl Chews estdio right now (thanks for a nice and working system Earl), and similar works will be very wellcome. Your (C)'s will of course be left intact. Drop me a line if you are willing to let me use your code. Linus PS. to PHIL NELSON! I'm unable to get through to you, and keep getting "forward error - strawberry unknown domain" or something. =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: Beginner asking questions. Message-ID: <1991Oct21.184940.27505@klaava.Helsinki.FI> Date: 21 Oct 91 18:49:40 GMT References: <1991Oct21.154757.9187@convex.com> Distribution: comp.os.minix Organization: University of Helsinki Lines: 29 In article <1991Oct21.154757.9187@convex.com> capps@convex.com (Don Capps) writes: > > I am new to minix. I am interesting in knowing if a version > exists that has pageing and swapping ( For those PC`s with > an MMU) ? > > Thanks ahead of time. > capps@orion.convex.com Ok, it is obviously time for a small plug once more :-) There is an experimental FREE minix-like thing which supports paging (not yet to disk, but using the MMU to share pages after a fork etc etc), written only for 386 AT's. It currently isn't very practical, even though a number of people have a running system. It is a bit faster than minix (except the floppy-disk driver which really sucks :-). This is a kernel for hackers, so if you aren't one, you'd better wait for a later release. If anybody wants to look at the sources, there is a version available from 'nic.funet.fi' by anonymous FTP. There are also some binaries for the kernel there (gcc, tar, make, uemacs and fileutils). All this can be found in /pub/OS/Linux. This version currently needs minix-386 to compile (but in a week I'll have a bootable version there, I think). Anybody interested can finger me, or mail me for info, or just ftp some of the text-files from nic. Word of warning: it needs 4MB to be usable. Linus (torvalds@kruuna.helsinki.fi) ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: [comp.os.minix] Free minix-like kernel sources for 386-AT Summary: Still only ftp Message-ID: <1991Oct31.101252.13981@klaava.Helsinki.FI> Date: 31 Oct 91 10:12:52 GMT References: <3255@cluster.cs.su.oz.au> Organization: University of Helsinki Lines: 50 In article moroz@inzer.demos.su writes: >chrisa@extro.ucc.su.OZ.AU (C. G. Albone) writes: >>Hello all.. >> I missed the original posting, so could someone please tell me >>how I may obtain the sources. > And me too !!!!!!!!!!!!!! > Also, are them available via e-mail (mail server or smth), as I'm >in the former Soviet Union and can't do any FTP. Ok, as I've gotten quite a few questions, I guess I'd better follow up again. Linux is currently ONLY available via ftp from nic.funet.fi, directory /pub/OS/Linux. As the sources change rather rapidly (next release due out this weekend after I have tested some more), it is also currently impractical to make them available from other places. There is a mail-server possibility fron nic, but I think it's still in testing (you could try mailing "mailserver@nic.funet.fi" with "help" in the body, but I don't know if it will work). Linux is a full kernel that has so far worked on a number (5-10?) of at-386 (and one 486 as far as I know). It supports GNU cc (gcc), bash and some other free stuff. It is currently more of a hackers kernel (and minix-386 is needed, but that will change with this weeks release), and the current version number is 0.03 (next is 0.10 I think). Good things about linux: - it's free, full source, and I try to correct bugs you find. - it's a bit faster than minix, I think. - uses paging for memory management (not to disk yet) - multithreaded fs (but then you can get patches to minix that do similar stuff) - mostly full termios and vt100-console. - most things easy to port (easier than to minix). Bad points: - ONLY 386/486 - early versions: there might be lots of bugs, and you might need to port/hack things to work. - minix is recommended even for the upcoming version that doesn't absolutely need it. - currently only VGA (EGA?) support, limited keyboard drivers (US and Finnish) etc You can mail me for more info. "finger torvalds@kruuna.helsinki.fi" might tell you something too. Linus (torvalds@kruuna.helsinki.fi) ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix,comp.binaries.ibm.pc.d,comp.os.coherent,comp.os.mach,comp.os.misc,comp.unix.sysv386,comp.unix.programmers,gnu.misc.discuss Subject: Linux information sheet (non-monthly posting) Summary: free unix in beta Keywords: i386 unix Message-ID: <1992Jan9.121044.18825@klaava.Helsinki.FI> Date: 9 Jan 92 12:10:44 GMT Organization: University of Helsinki Lines: 150 This is a blatant plug for my own unix-like kernel, as I'm always interested in more beta-testers. It should be self-explanatory, although interested persons should note that version 0.12 (still beta) will be out in a week or so. 0.12 will have some additional features, most notably: - real paging to/from disk (but gcc is /slow/ on a 2M machine) - POSIX job control - virtual consoles & pty's - some 387-emulation but no, it doesn't do X yet. It looks a lot like minix, if you are familiar with that (but much better, of course :). LINUX IS STILL IN BETA!! You are probably not interested in this if you only know DOS - it helps /a lot/ if you have managed unix even a little: used minix or similar. Reading C-source and understanding what happens is another nice ability. Being beta also means it has many potential bugs, so watch out (although 0.11 seems to have been relatively stable). This information sheet has been compiled by Robert Blum (blum@cip-s01.informatik.rwth-aachen.de), but he has problems posting it. Questions/suggestions about the SHEET should go to him, about Linux either to me or to the mailing-list. Linus (torvalds@kruuna.helsinki.fi) PS. Sorry about the 100+ newsgroups (well, 8 I think) - I'm not certain which groups would be best. -------------------------------------------------- LINUX INFORMATION SHEET (last updated 13 Dec 1991) 1. WHAT IS LINUX 0.11 LINUX 0.11 is a freely distributable UNIX clone. It implements a subset of System V and POSIX functionality. LINUX has been written from scratch, and therefore does not contain any AT&T or MINIX code--not in the kernel, the compiler, the utilities, or the libraries. For this reason it can be made available with the complete source code via anonymous FTP. LINUX runs only on 386/486 AT-bus machines; porting to non-Intel architectures is likely to be difficult, as the kernel makes extensive use of 386 memory management and task primitives. Version 0.11 is still a beta release, but it already provides much of the functionality of a System V.3 kernel. For example, various users have been able to port programs such as bison/flex without having to modify code at all. Another indication of its maturity is that it is now possible to do LINUX kernel development using LINUX itself and freely-available programming tools. 2. LINUX features - System call compatible with a subset of System V and POSIX - Full multiprogramming (multiple programs can run at once) - Memory paging with copy-on-write - Demand loading of executables - Page sharing of executables - ANSI compliant C compiler (gcc) - A complete set of compiler writing tools (bison as yacc-replacement, flex as lex replacement) - The GNU 'Bourne again' shell (bash) - Micro emacs - most utilities you need for development (cat, cp, kermit, ls, make, etc.) - Over 200 library procedures (atoi, fork, malloc, read, stdio, etc.) - Currently 4 national keyboards: Finnish/US/German/French - Full source code (in C) for the OS is freely distributable - Full source code of the tools can be gotten from many anonymous ftp sites (Almost the entire suite of GNU programs has been ported to Linux.) - Runs in protected mode on 386 and above - Support for extended memory up to 16M on 386 and above - RS-232 serial line support with terminal emulation, kermit, zmodem, etc. - Supports the real time clock 3. HARDWARE REQUIRED - A 386 or 486 machine with an AT-bus. (EISA will probably work, also, but you will need an AT-bus hard disk controller.) Both DX and SX processors will work. - A hard disk implementing the standard AT hard disk interface-- for example, an IDE drive. SCSI drives are not supported yet. - A high-density disk drive--either 5.25" (1.2MB) or 3.5" (1.44MB). - At least 2 megabytes of RAM. (LINUX will boot in 2 Mb. To use gcc at least 4 MB are required.) - Any video card of the following: Hercules,CGA,EGA,VGA In addition, LINUX supports - Up to two serial lines - A real time clock 4. PARTIAL LIST OF UTILITIES INCLUDED IN OR AVAILABLE FOR LINUX 0.11 - The MTOOLS package (reading/writing to DOS filesystems) - The complete GNU filetools (ls, cat, cp, mv, ...) - The GNU C compiler with GNU assembler, linker, ar, ... - bison - flex - rcs - pmake (BSD 4.3 Reno/BSD 4.4 make) - kermit - Micro emacs - less - mkfs - fsck - mount/umount 5. LINUX BINARIES The LINUX binaries and sources are available at three anonymous FTP sites. These are: nic.funet.fi:/pub/OS/Linux tsx-11.mit.edu:/pub/linux tupac-amaru.informatik.rwth-aachen.de:/pub/msdos/replace 6. LEGAL STATUS OF LINUX Although LINUX is supplied with the complete source code, it is copyrighted software. Unlike MINIX, however, it is available for free, provided you obey to the rules specified in the LINUX copyright. 7. NEWS ABOUT LINUX Since LINUX's introduction to the public there has been a rapidly growing mailing list, "linux-activists@niksula.hut.fi". To subscribe to this list, mail to "linux-activists-requests@niksula.hut.fi". If the traffic in this lists increases further, there are plans to swap ( at least partially ) over to comp.os.misc, so watch out for any LINUX articles in this group. For the current status of LINUX, do "finger torvalds@kruuna.helsinki.fi". 8. FUTURE PLANS Work is underway on LINUX version 1.0, which will close some of the gaps in the present implementation. Various people are currently working on: - Math support/fp emulation in the kernel - Page swapping (since paging is already implemented) - A virtual filesystem layer - STREAMS - POSIX job control (This is already alpha and will probably be out with Version 0.12.) - init/getty/login - symbolic links - Interprocess communication - IEEE POSIX P1003.1 / P1003.2 compatibility - SCSI support If you want to help, join the mailing list. ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: Linux Message-ID: <1992Jan13.160250.25332@klaava.Helsinki.FI> Date: 13 Jan 92 16:02:50 GMT References: <1992Jan13.141829.2257@maths.tcd.ie> Organization: University of Helsinki Lines: 48 Sorry, but this post is too good just to leave hanging around :) In article <1992Jan13.141829.2257@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes: >Is any independent person actually running Linux, >and can give an opinion on its merits >vis-a-vis 386-Minix? Ok, somebody else should answer this, I can only say that the latest count on the activists-list is 196. Some of them are actually using linux. Many are just interested, and aren't actually going to use it, but there are quite a few that have started making changes and sending in patches: About half the new things in 0.12 have been implemented by others (job control, ptys, select, and virtual consoles are mostly tthe work of others, although I have hcaked them heavily) >While I could be convinced on this, >it seems to me pretty unlikely on the face of it >that anyone could really write a reliable operating system >from scratch in a short time. > >After all, it took Tanenbaum years to write Minix, >and he worked night and day without stop, [ editors note: he probably slept alternate sundays so that he could start afresh for next fortnights hacking. ast, can you confirm :-? ] >and had a team working under him too. >One only has to look at the sources >to see the sheer intellectual work involved >in such an enterprise. Are you writing this seriously? There are a lot of smileys missing. The reason unix has been so successful is that it's actually a very clean and simple operating system. I would seriously doubt anybody will implement VMS in a year (or 5, and even after that I wouldn't want to actually use it :-) On the off chance that this was a real post, and not just a joke then: yes, linux is a viable alternative to minix-386. Minix has a bigger base, and "the book", which are definitive advantages, but if a person knows unix a bit, then linux is entirely possible to use. There are bugs, and "reliable" might be too strong a word for linux still, but most things are easier to do under linux than under minix. Porting is much easier (I remember porting bash-1.05 to minix: it wasn't just "make and go".) Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: A doubt about Linux Message-ID: <1992Jan16.111400.7038@klaava.Helsinki.FI> Date: 16 Jan 92 11:14:00 GMT References: <1992Jan16.011837.16304@utdallas.edu> Organization: University of Helsinki Lines: 23 In article <1992Jan16.011837.16304@utdallas.edu> $user@utdallas.edu writes: >I remember reading a(may be several) posting that mentions that curently >available version of Linux (is it .11) [ actually 0.12 is out] > does not have init/login. Then am I >correct in presuming that I will always be root in Linux. Does this mean that >I cannot change my uid and change my previlege level (or is it just that >you don't have login/su to do it.). As you can see, I am confused by the real >meaning of the phrase "init/login not available". There is no problem with writing a small C-program to change your uid/gid - I use one myself (I write 'linus' on the command-line and get to be non-supervisor). This after I mistakenly tried to auto-dial my harddisk, and trashed a partition as root :) In fact there is now also available a small init/login - I haven't even had time to test it myself. I have to admit that all the protection features might not work very well: I haven't tested linux very much as non-root. Possibly you get to do things you shouldn't or you are unable to do things you should be able to do - that's what beta-testing is all about (as well as testing the drivers which don't work on all machines). Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: Linux-0.11 Message-ID: <1992Jan20.001203.18340@klaava.Helsinki.FI> Date: 20 Jan 92 00:12:03 GMT References: <1992Jan13.120357.5333@fel.tno.nl> <1992Jan14.090756.21579@colorado.edu> Followup-To: alt.os.linux Organization: University of Helsinki Lines: 18 In article sulkanen@xanth.msfc.nasa.gov (Martin Sulkanen - NRC/ES65) writes: > >what are the chances linux will be ported to macintosh? None. Or at least /very/ small. I wrote linux partly to learn the 386 architecture (and boy did I), so it uses every conceivable feature I could find. It is also written in assembler to a greater degree than really necessary (I wrote parts of linux defore I fully knew the gcc inline assembler syntax, so I wrote more in assembler when I started the thing than actually necessary). Also NOTE! I have changed the followup-to to alt.os.linux: comp.os.minix isn't the place to discuss linux, and this is absolutely the last post I'm going to answer on this forum, as people have been irritated by the number of posts. Sorry. For those not able to read the alt-groups, we are working on a comp.os.linux, but it will take time. Linus =============================== =============================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Message-ID: <1992Jan29.231426.20469@klaava.Helsinki.FI> Date: 29 Jan 92 23:14:26 GMT References: <12595@star.cs.vu.nl> Organization: University of Helsinki Lines: 91 Well, with a subject like this, I'm afraid I'll have to reply. Apologies to minix-users who have heard enough about linux anyway. I'd like to be able to just "ignore the bait", but ... Time for some serious flamefesting! In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >I was in the U.S. for a couple of weeks, so I haven't commented much on >LINUX (not that I would have said much had I been around), but for what >it is worth, I have a couple of comments now. > >As most of you know, for me MINIX is a hobby, something that I do in the >evening when I get bored writing books and there are no major wars, >revolutions, or senate hearings being televised live on CNN. My real >job is a professor and researcher in the area of operating systems. You use this as an excuse for the limitations of minix? Sorry, but you loose: I've got more excuses than you have, and linux still beats the pants of minix in almost all areas. Not to mention the fact that most of the good code for PC minix seems to have been written by Bruce Evans. Re 1: you doing minix as a hobby - look at who makes money off minix, and who gives linux out for free. Then talk about hobbies. Make minix freely available, and one of my biggest gripes with it will disappear. Linux has very much been a hobby (but a serious one: the best type) for me: I get no money for it, and it's not even part of any of my studies in the university. I've done it all on my own time, and on my own machine. Re 2: your job is being a professor and researcher: That's one hell of a good excuse for some of the brain-damages of minix. I can only hope (and assume) that Amoeba doesn't suck like minix does. >1. MICROKERNEL VS MONOLITHIC SYSTEM True, linux is monolithic, and I agree that microkernels are nicer. With a less argumentative subject, I'd probably have agreed with most of what you said. From a theoretical (and aesthetical) standpoint linux looses. If the GNU kernel had been ready last spring, I'd not have bothered to even start my project: the fact is that it wasn't and still isn't. Linux wins heavily on points of being available now. > MINIX is a microkernel-based system. [deleted, but not so that you > miss the point ] LINUX is a monolithic style system. If this was the only criterion for the "goodness" of a kernel, you'd be right. What you don't mention is that minix doesn't do the micro-kernel thing very well, and has problems with real multitasking (in the kernel). If I had made an OS that had problems with a multithreading filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my damndest to make others forget about the fiasco. [ yes, I know there are multithreading hacks for minix, but they are hacks, and bruce evans tells me there are lots of race conditions ] >2. PORTABILITY "Portability is for people who cannot write new programs" -me, right now (with tongue in cheek) The fact is that linux is more portable than minix. What? I hear you say. It's true - but not in the sense that ast means: I made linux as conformant to standards as I knew how (without having any POSIX standard in front of me). Porting things to linux is generally /much/ easier than porting them to minix. I agree that portability is a good thing: but only where it actually has some meaning. There is no idea in trying to make an operating system overly portable: adhering to a portable API is good enough. The very /idea/ of an operating system is to use the hardware features, and hide them behind a layer of high-level calls. That is exactly what linux does: it just uses a bigger subset of the 386 features than other kernels seem to do. Of course this makes the kernel proper unportable, but it also makes for a /much/ simpler design. An acceptable trade-off, and one that made linux possible in the first place. I also agree that linux takes the non-portability to an extreme: I got my 386 last January, and linux was partly a project to teach me about it. Many things should have been done more portably if it would have been a real project. I'm not making overly many excuses about it though: it was a design decision, and last april when I started the thing, I didn't think anybody would actually want to use it. I'm happy to report I was wrong, and as my source is freely available, anybody is free to try to port it, even though it won't be easy. Linus PS. I apologise for sometimes sounding too harsh: minix is nice enough if you have nothing else. Amoeba might be nice if you have 5-10 spare 386's lying around, but I certainly don't. I don't usually get into flames, but I'm touchy when it comes to linux :) =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Apologies (was Re: LINUX is obsolete) Message-ID: <1992Jan30.153816.1901@klaava.Helsinki.FI> Date: 30 Jan 92 15:38:16 GMT References: <12595@star.cs.vu.nl> <1992Jan29.231426.20469@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 12 In article <1992Jan29.231426.20469@klaava.Helsinki.FI> I wrote: >Well, with a subject like this, I'm afraid I'll have to reply. And reply I did, with complete abandon, and no thought for good taste and netiquette. Apologies to ast, and thanks to John Nall for a friendy "that's not how it's done"-letter. I over-reacted, and am now composing a (much less acerbic) personal letter to ast. Hope nobody was turned away from linux due to it being (a) possibly obsolete (I still think that's not the case, although some of the criticisms are valid) and (b) written by a hothead :-) Linus "my first, and hopefully last flamefest" Torvalds =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Message-ID: <1992Jan31.103323.29629@klaava.Helsinki.FI> Date: 31 Jan 92 10:33:23 GMT References: <12595@star.cs.vu.nl> <1992Jan29.231426.20469@klaava.Helsinki.FI> <12615@star.cs.vu.nl> Organization: University of Helsinki Lines: 68 In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >The limitations of MINIX relate at least partly to my being a professor: >An explicit design goal was to make it run on cheap hardware so students >could afford it. All right: a real technical point, and one that made some of my comments inexcusable. But at the same time you shoot yourself in the foot a bit: now you admit that some of the errors of minix were that it was too portable: including machines that weren't really designed to run unix. That assumption lead to the fact that minix now cannot easily be extended to have things like paging, even for machines that would support it. Yes, minix is portable, but you can rewrite that as "doesn't use any features", and still be right. >A multithreaded file system is only a performance hack. Not true. It's a performance hack /on a microkernel/, but it's an automatic feature when you write a monolithic kernel - one area where microkernels don't work too well (as I pointed out in my personal mail to ast). When writing a unix the "obsolete" way, you automatically get a multithreaded kernel: every process does it's own job, and you don't have to make ugly things like message queues to make it work efficiently. Besides, there are people who would consider "only a performance hack" vital: unless you have a cray-3, I'd guess everybody gets tired of waiting on the computer all the time. I know I did with minix (and yes, I do with linux too, but it's /much/ better). >I still maintain the point that designing a monolithic kernel in 1991 is >a fundamental error. Be thankful you are not my student. You would not >get a high grade for such a design :-) Well, I probably won't get too good grades even without you: I had an argument (completely unrelated - not even pertaining to OS's) with the person here at the university that teaches OS design. I wonder when I'll learn :) >My point is that writing a new operating system that is closely tied to any >particular piece of hardware, especially a weird one like the Intel line, >is basically wrong. But /my/ point is that the operating system /isn't/ tied to any processor line: UNIX runs on most real processors in existence. Yes, the /implementation/ is hardware-specific, but there's a HUGE difference. You mention OS/360 and MS-DOG as examples of bad designs as they were hardware-dependent, and I agree. But there's a big difference between these and linux: linux API is portable (not due to my clever design, but due to the fact that I decided to go for a fairly- well-thought-out and tested OS: unix.) If you write programs for linux today, you shouldn't have too many surprises when you just recompile them for Hurd in the 21st century. As has been noted (not only by me), the linux kernel is a miniscule part of a complete system: Full sources for linux currently runs to about 200kB compressed - full sources to a somewhat complete developement system is at least 10MB compressed (and easily much, much more). And all of that source is portable, except for this tiny kernel that you can (provably: I did it) re-write totally from scratch in less than a year without having /any/ prior knowledge. In fact the /whole/ linux kernel is much smaller than the 386-dependent things in mach: i386.tar.Z for the current version of mach is well over 800kB compressed (823391 bytes according to nic.funet.fi). Admittedly, mach is "somewhat" bigger and has more features, but that should still tell you something. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: Unhappy campers Message-ID: <1992Feb6.103331.19702@klaava.Helsinki.FI> Date: 6 Feb 92 10:33:31 GMT References: <12667@star.cs.vu.nl> <205@fishpond.uucp> <12746@star.cs.vu.nl> Organization: University of Helsinki Lines: 75 In article <12746@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >If Linus wants to keep control of the official version, and a group of eager >beavers want to go off in a different direction, the same problem arises. This is the second time I've seen this "accusation" from ast, who feels pretty good about commenting on a kernel he probably haven't even seen. Or at least he hasn't asked me, or even read alt.os.linux about this. Just so that nobody takes his guess for the full thruth, here's my standing on "keeping control", in 2 words (three?): I won't. The only control I've effectively been keeping on linux is that I know it better than anybody else, and I've made my changes available to ftp-sites etc. Those have become effectively official releases, and I don't expect this to change for some time: not because I feel I have some moral right to it, but because I haven't heard too many complaints, and it will be a couple of months before I expect to find people who have the same "feel" for what happens in the kernel. (Well, maybe people are getting there: tytso certainly made some heavy changes even to 0.10, and others have hacked it as well) In fact I have sent out feelers about some "linux-kernel" mailing list which would make the decisions about releases, as I expect I cannot fully support all the features that will /have/ to be added: SCSI etc, that I don't have the hardware for. The response has been non-existant: people don't seem to be that eager to change yet. (well, one person felt I should ask around for donations so that I could support it - and if anybody has interesting hardware lying around, I'd be happy to accept it :) The only thing the copyright forbids (and I feel this is eminently reasonable) is that other people start making money off it, and don't make source available etc... This may not be a question of logic, but I'd feel very bad if someone could just sell my work for money, when I made it available expressly so that people could play around with a personal project. I think most people see my point. That aside, if Fred van Kempen wanted to make a super-linux, he's quite wellcome. He won't be able to make much money on it (distribution fee only), and I don't think it's that good an idea to split linux up, but I wouldn't want to stop him even if the copyright let me. >I don't think the copyright issue is really the problem. The problem is >co-ordinating things. Projects like GNU, MINIX, or LINUX only hold together >if one person is in charge. Yes, coordination is a big problem, and I don't think linux will move away from me as "head surgeon" for some time, partly because most people understand about these problems. But copyright /is/ an issue: if people feel I do a bad job, they can do it themselves. Likewise with gcc. The minix copyright, however, means that if someone feels he could make a better minix, he either has to make patches (which aren't that great whatever you say about them) or start off from scratch (and be attacked because you have other ideals). Patches aren't much fun to distribute: I haven't made cdiffs for a single version of linux yet (I expect this to change: soon the patches will be so much smaller than the kernel that making both patches and a complete version available is a good idea - note that I'd still make the whole version available too). Patches upon patches are simply impractical, especially for people that may do changes themselves. >>Where is the sizeable group of people that want to evolve gcc in a way that >>rms/FSF does not approve of? >A compiler is not something people have much emotional attachment to. If >the language to be compiled is a given (e.g., an ANSI standard), there isn't >much room for people to invent new features. An operating system has unlimited >opportunity for people to implement their own favorite features. Well, there's GNU emacs... Don't tell us people haven't got emotional attachment to editors :) Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: MInix386 > Linux0.95c+ Message-ID: <1992Apr27.090224.25223@klaava.Helsinki.FI> Date: 27 Apr 92 09:02:24 GMT References: <1992Apr23.082847.13947@ntuix.ntu.ac.sg> Organization: University of Helsinki Lines: 43 In article <1992Apr23.082847.13947@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes: >I had just tried Linux 0.95c+ for a few minutes. I was not impressed. Well, maybe it takes time to see all the good points... :) > The much acclaimed virtual memory was not possible because I do not >have a partition for testing the swapon. I only have 4 partitions. 2 for DOS. >1 for Minix 16 bit. You can also use a swap-file: it's a bit slower, but most people seem to prefer it due to ease of setting up and size changes. > The multi-threaded file system is not apparent as I do not detect any >speed improvement. I only test it for a few minutes. I had not downloaded >software. Minix is in fact faster on some things: the minix harddisk driver has been hacked heavily (mainly thanks to bruce evans I think) for perfomance to overcome the single-threading. Linux has no speed hacks: it depends solely on the cleaner interface, and even so it's in the same class and sometimes noticeably faster than minix. > Linux does not have debuggers yet which is a serious limitation. >From the alt.os.linux, there are complaints that with swapping on, the system >becomes too slow. Surprise surprise: swapping slows down your machine... Try running gcc under minix in 2MB and see what happens. Even with 4MB gcc-2.1 can seriously deplete you memory, and swapping is your only way out. Also, linux does have a debugger: gdb-4.5 (the newest version) works ok with the new kernel. I've had no problems at all, although the lack of core-dumps is a minor irritation. > I do not need virtual memory because I have 8 Mbyte or 16 Mbyte > but I need shared text which I have not managed to install to my > Minix386 yet. Well, with X (already working, but not available for "the masses") even 8MB is pretty small. minix-386 has been available for a /long/ time, but nobody even tried to port X - and don't tell me it was lack of interest. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: minix kernel structure Message-ID: <1992Jun25.093528.5468@klaava.Helsinki.FI> Date: 25 Jun 92 09:35:28 GMT References: <1992Jun24.121431.22027@philce.ce.philips.nl> Organization: University of Helsinki Lines: 38 In article <1992Jun24.121431.22027@philce.ce.philips.nl> meulenbr@ce.philips.nl (Frans Meulenbroeks) writes: [ good things deleted ] >This core should have the following functions: >- context switching >- message passing >- basic clock handling >- memory copying between tasks >- support for interrupt handling >- creation and removal of processes. >- system call dispatching (perhaps this should be done by a special task) Everything you said sounds very reasonable, but I'd suggest (a) no memory copying between tasks: messages should be used instead (b) add mm primitives to the core (get_area, map_area, umap_area etc) (a) is pretty clear: the current minix memory-copy function is horrible, and shouldn't work in a real microkernel. (b) shouldn't be a memory-management server, but instead support the paging etc hardware. That means giving processes controlled access to the page tables (via messages) and send out messages to the processes depending on page faults etc. The real mm process would use this to implement demand-paging etc, but the core itself should do the nitty-gritty details. (b) should also let processes add their own page-fault handlers and such, mapping in new memory and initializing it as they wish etc. And I think system call dispatching shouldn't be done by the core, but by a special server. I'd also suggest adding threading support: the fs and mm processes need to be multithreaded (or page faults etc are very difficult indeed to handle, as a page-fault can happen in the fs process and often needs the fs process to be handled). Linus =========================== =========================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: minix kernel structure Message-ID: <1992Jun26.180727.15763@klaava.Helsinki.FI> Date: 26 Jun 92 18:07:27 GMT References: <1992Jun24.121431.22027@philce.ce.philips.nl> <1992Jun25.093528.5468@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 120 In article meulenbr@prl.philips.nl (Frans Meulenbroeks) writes: >torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes: > >>(a) no memory copying between tasks: messages should be used instead > >Yes, you are right. However, there are a few cases where you want to >pass more data than fit in a message. You could pass a pointer into the >message, but you cannot use it in another program if you have memory >management. The idea should be that messages can have any length, and the message-passing code in the kernel does the copying. Thus a read() or something would be implemented like this: - user process sends a message to the fs process (possibly going through a system call server) that requests a read(). This message wouldn't even contain the buffer address, just which file and how much you want to read. - the user process does a receive() and blocks. This receive is what contains the address to be copied to. - the fs process responds with a message that contains the data. The fs doesn't even know where the data goes to, it just replies to a request, and the message-passing code automatically copies the data to the right place (as it knows where the process expects it due to the receive). Fixed-size messages are a pain, and should be banned: you lose most of the nice properties of messages that way. > > [mm in the core] > >This is maybe also a good idea. I should think about it some more. >However, I think that the original proposal is already enough work >without this added. Better first get the original proposal implemented. >Later on we can discuss how mm should be. Yes, you definitely have enough to do even without my suggestions. I still think that even without paging, you should have the low-level memory management routines in the core, and if you want a mm process, it shouldn't be able to claim memory left and right. I think even amoeba has the memory-management in the kernel (Andy?). Then having a mm process that does the more high-level things (like actually loading executables etc) is a good idea. >A system call server sounds like a very good idea to me. In fact I have >already been thinking about it. I'm tempted to keep the proposal as >small as possible, so for the time being I have left it out. To me >however this would be one of the first things to add after implementing >my proposal. I'd suggest that you'd implement some kind of message redirection, so that the system call server wouldn't have to direct messages both ways. For example, a read() system call might happen something like this with a redirecting syscall handler: (a) User does a send-receive to the system call handler (b) the syscall handler decides which process to redirect the message to. (c) the fs process (which got the redirected message) decides which handler process (eg the tty process) and redirects it to that process. (d) the tty process replies to the message directly to the user process due to the redirection. Note that without redirection, a lot more messages need to be passed (tty process replies to fs process which replies to syscall handler which replies to the user process), which means the system is doing a lot of context switches. With redirection you can sometimes get only half the number of messages, and it might mean that things like the system call handler wouldn't have to be multithreaded as it can do any requests without blocking. >My thoughts about multithreading are mixed. >On the one side I like the performance gain. On the other hand this >complicates things, so it does not really fit into the minix scope. Multi-threading isn't a question of performance: you generally get better performance too, but the most important part is that some things are impossible or much more complicated without multithreading. I already mentioned demand-paging and virtual memory that effectively /need/ multithreading, but some other quite mundane things are simply not possible to do without it. The filesystem simply /has/ to be multithreaded or you need a lot of ugly hacks. Look at the tty code in the minix fs: it's not exactly logical or nice. As a tty request can take a long time, minix has to do small ugly hacks to free the fs process as fast as possible so that it can do some other request while the tty is hanging. It does a messy kind of message redirection, but it's really rather nasty (as the redirection isn't a kernel primitive, but an ugly hack to get this particular problem solved). Not having multithreading also results in the fact that the system tasks cannot send each other messages freely: you have to be very careful that there aren't dead-locks where different system calls try to send each other messages. Ugly. Having multithreaded system tasks would make a lot of things cleaner (I don't think user tasks need to be able to multithread, but if the kernel supports it for system tasks, it might as well work for user tasks as well). So while it's true that multithreading actually results in a performance increase, that is /not/ the most important reason to implement it. It's just another good point. Note that the above arguments are just (a) personal opinions (b) what I consider to be a "clean" system [*]. Obviously you can have a message- passing fs that isn't multithreaded (as in the current minix implementation), but my point is that it leads to ugly hacks and removes a lot of the good points of messages. What's the idea in using minix as a teaching tool if it does some fundamentally buggy things? Linus [*] I know people might not consider linux "clean", but it is: it does what it set out to do cleanly and well. I find minix irritating in that it considers itself a good system, but is so badly implemented that all the good points drown in the hacks needed to get it going. (Don't flame me too badly for that last comment: I'm just drivig in the point as I see it.) ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.coherent,comp.os.minix Subject: Re: OS compare (Unix/clone) Message-ID: <1992Jul29.172406.29587@klaava.Helsinki.FI> Date: 29 Jul 92 17:24:06 GMT References: <1992Jul28.154817.5839@mtu.edu> Organization: University of Helsinki Lines: 40 In article Petri.Virkkula@hut.fi (Petri Virkkula) writes: > > Haven't I understood something correctly? Isn't it possible to > swap segments to disk using Valid and Accessed flags in > segment descriptors? Yes, it's certainly possible, but it's also almost never worth the bother: it's slow, hard to program, and writing a C-compiler (and probably any other language) to understand several segments while still being efficient is pretty hard. And having just one code-segment and one data (and stack) segment is simply not enough for a lot of interesting applications. Having several different code/date-segments doesn't lend itself very well to high-level languages (it doesn't even work too well in assembly, but there the programmer often knows what he/she is doing). Thus coherent 3.2 and minix don't even try: they keep to one segment, and limit all data to 64kB. You can do a lot in 64kB, but I'd rather miss the experience. OS/2 1.x tried to implement a "real" system on a 286, and while some people think it worked well, most people (including the OS/2 2.0 designers) seem to agree that the 286 protected mode memory management is simply not enough for any good real system. Of course, you can still use them for DOS or some other embedded system (a toaster, washing machine etc). That doesn't mean the 386 is perfect: it has got it's own number of idiocyncracies (especially when used in AT hardware). But at least you don't have to fight the hardware all the way if you want to do something bigger on a 386. Linus PS. "Being able to" and "suitable for" are totally different things: you can write a fully multitasking VM system with 32-bit pointers on a Z80 (for example by writing a 386 (or why not a cray-XMP?) emulator on it), and all general-purpose processors are theoretically able to solve the same set of problems. Thus even a lowly 286 can provably do the same things a 386 does. It's just not worth it in most cases. ======================== ======================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: GNU-C recompiled minix wanted Message-ID: <1992Sep3.122349.16731@klaava.Helsinki.FI> Date: 3 Sep 92 12:23:49 GMT References: <1992Sep3.103808.12710@mnemosyne.cs.du.edu> Organization: University of Helsinki Lines: 22 In article <1992Sep3.103808.12710@mnemosyne.cs.du.edu> vromano@nyx.cs.du.edu (Vincenzo Romano) writes: >I'm looking for a copy of the Minix Operating System recompiled by using >the GNU-C compiler. I already own the Minix 1.5 but I'm sure that on my >386sx machine such a recompiled OS should be faster, isn't it? > >Can anyone help me? Can anyone tell me where I can FTP this OS or, at least >a pre-compiled minix port of the GNU-C? As far as I know, there is no gcc-compiled version of PC-minix available. Gcc won't even run on the basic minix setup: you have to upgrade to 386-minix by Bruce Evans (this is a good idea anyway, as it allows you to run other programs that won't work under normal minix otherwise). The 386-patches are available (or were when I got them) at least from plains.nodak.edu, (/pub/minix/oz/ I think). If you don't have to run minix, you could be better off trying out linux or 386bsd instead: they give you everything minix does and then some (and is compiled using gcc). For good performance you need at least 4MB of memory, though, or you'll swap your brains out trying to run all the GNU software. Read comp.os.linux/comp.unix.bsd for additional info. Linus =============================== =============================== From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: (none given) Message-ID: <1992Sep11.120003.27063@klaava.Helsinki.FI> Date: 11 Sep 92 12:00:03 GMT References: <1992Sep11.093444.223@email.tuwien.ac.at> Organization: University of Helsinki Lines: 35 [ egg on my face - I didn't think a gcc-compiled minix existed at all. Btw, did you rewrite all the .x files in gas syntax, or are you using some weird combination of gcc/bcc/bas? ] In article etlmike@jerry.ericsson.se (Mike Wilcox) writes: > >Hmmm - it is very slow when no options are used. I have many >screenful's of benchmark speeds with the kernel compiled with >different compilers, and different options (especially to GCC). >Also with different speeds for different versions of GCC! > >I think best compilation is with -O -fomit-frame-pointer >-fstrength-reduce -fcombine-regs. You might also try gcc-2.2.2, which gives some noticeable speed increases under some circumstances (notably floating-point which is essentially useless under minix unless you have patched that too, but integer performance is also better). >I seem to remember that using -finline-functions actually made things >worse. If anyone can explain THAT one to me, I'd be grateful! This could be related to the general gcc speed decrease: has the kernel by any chance grown noticeably? -finline-functions (and some other options line -fstrength-reduce, -m486) can make the executable image noticeably bigger. In general, gcc doesn't even try to make things small, and binaries compiled with gcc can be bigger than those of other compilers. Size is normally not a problem, but if your minix has buffer-size limitations (low 1MB or similar - I know the version I used had that limit), over-all performance can go down due to much smaller buffer space. Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: Linux? Message-ID: <1992Sep21.123312.27713@klaava.Helsinki.FI> Date: 21 Sep 92 12:33:12 GMT References: <1992Sep21.110338.21830@udel.edu> Followup-To: comp.os.linux Organization: University of Helsinki Lines: 60 In article <1992Sep21.110338.21830@udel.edu> S90405184@hsepm1.hse.nl writes: > >Can smebody, in a few wrds, tell me wha linux is? >I've seen it mentined in info minix a few times. [ This should be in comp.os.linux - see the Follow-Up. If you have c.o.minix, but not c.o.linux, you should contact your newsfeed administrator ] Linux is a unix-like OS for the 386 - it's *not* available for any other architecture (and it currently doesn't work even on PS/2 (ie MCA) machines). Like minix, it comes with full source code, and is copyrighted. Unlike minix, it's freely re-distributable under the GNU copyleft (ie it doesn't cost you anything if you have ftp access). Linux has some ties the the minix community: I originally used minix for linux developement, and the standard filesystem is still mostly compatible with the original minix fs (ie you can mount the same partitions both from minix and linux). That's about the only thing minix/linux have in common any more, but it may make a transition easier. The best way to get a picture of linux is probably to read comp.os.linux for a while, and/or ftp to 'tsx-11.mit.edu' (pub/linux) or 'nic.funet.fi' (pub/OS/Linux) and try it out. Documentation isn't too hot (if you are timid about that, you should probably get minix or coherent), but it's possible to set up a linux system even with very limited unix knowledge. Linux runs in full 32-bit protected mode, giving each process a 3GB process space (1GB used for virtual kernel memory). It supports paging to disk, shared libraries etc, and runs about everything from gcc to X11r5. 2MB physical RAM minimum, with >=4MB preferred for good performance. Linux supports virtual filesystems: the standard kernel understands the minix fs, DOS disks (non-stacked), and a ext-fs format, giving 255 char character names and bigger partitions than the minix format. There are also patches for a xenix-filesystem mode as well as for actual emulation of some xenix binaries (but this isn't part of the standard kernel). Additional patches include tcp/ip (which will be in the next major release, probably next week), a soundblaster driver and a CDROM fs. There is some work going on to use linux as the base for the FSF single-server (ie not Hurd, but a simpler unix-server) on top of mach-3.0, but this is so far only in it's infancy. Additional info from the newsgroup and ftp-sites. I'd also suggest you check out "comp.os.coherent" and "comp.unix.bsd" for other alternatives to DOS - while I obviously think linux is the best of minix/linux/coherent/386bsd, there are those who disagree: Minix is good for education (source, the book), coherent for simpler home use (easier installation, manual), linux for hacking (source, completeness) and 386bsd for people who simply want "the real McCoy" (source, compatibility). Linux and 386bsd are both freely distributable, although under different conditions, while minix and coherent are commercial (although cheap: $169 v $99 USD). Linus ========================= ========================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: source code to standard library functions Message-ID: <1992Oct1.185039.14249@klaava.Helsinki.FI> Date: 1 Oct 92 18:50:39 GMT References: <9929@kralizec.zeta.org.au> Organization: University of Helsinki Lines: 18 In article <9929@kralizec.zeta.org.au> craig@kralizec.zeta.org.au (Craig Dewick) writes: > >I'm trying to get access to the source code of the standard library functions >provided with Unix/Minix/etc., but so far I've had no luck. > >Is is possible to gain access to source for these functions somewhere? If you have no problems with the GNU copyleft, I'd suggest you take a look at the GNU libc.a replacement. It's starting to get pretty complete and working, and you should be able to find it on most bigger ftp-sites that carry GNU software (the only one I know about is at nic.funet.fi: pub/gnu/glibc-1.05.tar.Z, but you should be able to find something nearer). You'd probably have to hack on it some, but at least it's a starting point. Linus ============================== ============================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: Dynamically Linked Libraries? Message-ID: <1992Oct16.152838.2655@klaava.Helsinki.FI> Date: 16 Oct 92 15:28:38 GMT References: <1992Oct16.132202.892@udel.edu> <1992Oct16.140510.25779@mnemosyne.cs.du.edu> Organization: University of Helsinki Lines: 35 In article <1992Oct16.140510.25779@mnemosyne.cs.du.edu> hpoe@nyx.cs.du.edu (Howard Poe) writes: >Glen Cornell writes: >> >>AmigaDOS, as well as MS-Windows, provide the capability of linking >>object code to a program at run-time. >> >>How does an OS dynamically link object code? Is it taken care of in >>the kernel? >>Is it possible for an OS like MINIX or UNIX to have this capability? > >Linux now uses a similar scheme for linking object files at runtime. >Maybe you can check it out. Yes, linux has shared libraries (X is a pain without them - both in memory and disk usage), but it's not actually done using dynamic linking, but by a simpler scheme which essentially just mmap()'s the library at a hardcoded address. This is fine and works, but if you really want dynamic linking (not that I see why), you'll have to look elsewhere. They were talking about it over in comp.os.bsd for 386bsd - I don't know if anything got decided (using hardcoded addresses and jump-tables like under linux, or doing truly dynamic libraries both have their good and bad sides). As to how dynamic linking is done - it can be done totally in user space (essentially just running 'ld' on the binary at startup or by having stub functions that load in the library when they get called), but for good performance you would probably want kernel support (in order to be able to share pages between different invocations of the same library etc). Getting dynamic linking right seemed too hairy for the good points it offers, so linux went with the simpler scheme where all the work is done at library creation time. This may be slightly less flexible, but it's much easier (and it does have some other good points too). Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: NNTP under MINIX Message-ID: <1992Oct30.161022.19335@klaava.Helsinki.FI> Date: 30 Oct 92 16:10:22 GMT References: <1992Oct29.081417.1951@udel.edu> Organization: University of Helsinki Lines: 28 In article philip@cs.vu.nl (Philip Homburg) writes: >In article klamer@mi.el.utwente.nl (Klamer Schutte) writes: >%Three certainly are enough? Things like TCP/IP is needed for minix to >%keep up with other UNIX flavours. Now somebody who: >% 1) NFS running ;-) > >An NFS server is no problem (the v2 filesystem can even store a 32 bit >protection key in the inode). An NFS client that can be mounted (apposed to >a user level shell like ftp) will be very hard. The server just needs tcp/ip - the nfs client needs a *lot* of rewriting in the minix fs and might be more trouble than it's worth. You'd essentially need a vfs layer to take care of different types of filesystems, and I don't think this is supported even with the new kernels can handle different fs's (I assume the new minix fs isn't really NEW - I guess it's only a case of extending the inode and block nr fields). >% 2) get X11 running ;-) > >Also not very hard, just a lot of work. Infact I know a minix system that >runs X11R5 clients over TCP/IP :-) Yours? Again, the *real* fun comes in when you can run the X11 server on the system. After all, most minix machines probably don't have a X terminal or Sun hooked up to them.. Linus "yes, linux does it all" Torvalds =========================== =========================== Newsgroups: comp.os.minix From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: Is MINIX much better than LINUX? Message-ID: <1992Dec12.090926.28084@klaava.Helsinki.FI> Organization: University of Helsinki References: <1992Dec12.034538.14723@netcom.com> Date: Sat, 12 Dec 1992 09:09:26 GMT Lines: 75 In article <1992Dec12.034538.14723@netcom.com> sjs@netcom.com (Stephen Schow) writes: >I need some reasons for buying minix versus just getting linux for free. >Anyone got any concrete ones. I won't really be doing any commercial things. >I just want to get through my BSCS, where all of our programming has to be >on UNIX machines. Can't pass on this one... The simple answer is a resounding NO. There are two circumstances when you may find minix better: - studies with the book: minix documentation is better, and if you are reading the Tanenbaum book, minix will naturally be closer to what is covered in the text. - if linux won't run on your hardware (ie PS/2 or any non-386 hardware, or <2MB memory). Linux has all the features that minix has (except minix-specific things like amoeba support), as well as a lot of features minix doesn't have: - a real mm taking advantage of the 386 features. Virtual memory, demand-loading, shared pages, the works. There seem to be patches for some of this to minix as well, but I haven't heard how well they work. - multithreading filesystem. 'Nuff said. Available in a limited form for minix as a cludge. - better buffer cache handling. The cache grows/shrinks dynamically with memory consumption. - virtual filesystem layer: you can have several different fs's active at once. The current standard filesystems are: minix (old 1.5 type), extended (255 char filenames, 4GB partitions), msdos, proc (for process information), isofs (CDROM filesystem) and NFS client fs. - floating point support (ie you can use your coprocessor if you have one - the kernel makes sure processes don't mess with each others state) - coprocessor emulation (so that you can ignore the lack of coprocessor if you don't mind the performance hit) - netowrking support with tcp/ip and NFS (SLIP is in the works) - pretty much 100% POSIX and features from both sysv and bsd worlds: porting most stuff is mostly very simple. - X11 and most GNU software, as well as a lot of other free software out there. - shared libraries, so X11 binaries don't take up all your disk space.. - Active support (me + probably several thousand activists: c.o.linux has been on the top-40 lists of most active newsgroups for the last couple of months). And a lot more... Linux is lacking in (relative to some other unixes, not minix): - No sysv shared memory yet (well, there are patches, but not part of the official kernel), and no real mmap(). - Not binary compatible with anything - Documentation and "real" support (although the c.o.linux newsgroup is pretty good) - ...? Ok, after having beaten my breast about linux, I'd also better mention that 386bsd is also free, and has about similar features. Linux is better in some respects: it seems to work on a wider variety on machines and is actually stabler on some configurations. On the other hand, 386bsd has a more mature networking setup, as well as having the advantage of being "the real McCoy". Check out both comp.os.linux and comp.unix.bsd for details. Note that both linux and 386bsd are good for people who aren't afraid to set up the system themselves, and are willing to find documentation from various sources. Coherent (USD $99) might be an alternative if you want good printed manuals and don't care about X11 or features, but just want a simple working unix that has support and is easy to install. And although minix doesn't do as much as linux or 386bsd, and doesn't have the support of Coherent, it's still a real contender in academic courses etc. Linus ====================== ====================== Newsgroups: comp.os.minix From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: Is MINIX much better than LINUX? Message-ID: <1992Dec14.141659.7045@klaava.Helsinki.FI> Organization: University of Helsinki References: <1992Dec12.034538.14723@netcom.com> <1992Dec12.090926.28084@klaava.Helsinki.FI> <1ggtrdINN4tb@hrd769.brooks.af.mil> Date: Mon, 14 Dec 1992 14:16:59 GMT Lines: 37 In article <1ggtrdINN4tb@hrd769.brooks.af.mil> news@hrd769.brooks.af.mil (InterNet News) writes: >> >>Can't pass on this one... The simple answer is a resounding NO. >> > >Linus, > How soon they forget. They leave home and the folks seem like such >bumphins :-). > > You DID cut your operating system teeth on Minix, as I recall. It was >pretty spiffy at the time, wasn't it? Well, I used minix for half a year, but why do you think I wrote my own... Seriously, I agree with your points: minix is absolutely better than nothing, so on older (or non-clone) hardware it's perfectly fine, as well as for learning about unix. But the original question (in case anybody still remembers it instead of the linux-minix flame-war) was whether minix was much better than linux, with the obvious implication that he had the hardware to run either. And I've got enough of an ego not to let that kind of question go unanswered (besides, the minix group has been mostly empty lately, so it can't hurt to get some discussion going anyway). Also, Bruce Evans (general good guy and the author of the 386-minix patches as well as lots of other minix code) pointed out per email that some of the linux features can be gotten as patches (math support etc), and that some minix device drivers are better (with patches - mainly written by him I suspect) than the linux ones (the reverse is also true, of course). So it's not a question of linux being perfect, but assuming you have the hardware linux is generally much nicer to use and hack on than minix is. That doesn't detract from the usability of minix on other hardware (or in special circumstances like university studies etc). Linus ======================= ======================= Newsgroups: comp.os.minix From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: Is MINIX much better than LINUX? Message-ID: <1992Dec20.235535.4281@klaava.Helsinki.FI> Organization: University of Helsinki References: <1992Dec19.162027.1604@frmug.fr.mugnet.org> Date: Sun, 20 Dec 1992 23:55:35 GMT Lines: 58 In article <1992Dec19.162027.1604@frmug.fr.mugnet.org> archer@frmug.fr.mugnet.org (Vincent Archer) writes: > >So buy, buy more. I thought that the whole point of Linux was that it was >free? I'll have to spend $150 to buy a 386 board. Ok. Then what? No, the whole point of linux isn't that it's free, and never has been. It's one of the points that come up most regularly, as it's certainly something that gets the attention of most people. It's also one thing I stressed in the "linux is obsolete" flamewar, as it's one thing I think minix *should* have had as one of it's main points due to being meant for studies. In fact, if you want to, you can pay for your linux installation: there are at least two CD-roms available already which contain linux sources, and a third one seems to be in the making. Also, SLS in Canada sells linux on floppies. I'm not getting any money on them, but that doesn't mean they are giving linux away for no cost. And I don't mind, because 'free' wasn't the whole point, just a big plus. The *point* with linux is that I didn't have a good OS on my machine (I had DOS and minix, and my definition of good is obviously different from ast's), so I wrote one. Making it freely available was a separate decision not directly connected with the conception of it, and one that paid off handsomely: thanks to that it's now a lot better system than it would otherwise have been. It resulted both in me getting good feedback and testing for the system, as well as actual patches to make it run better: both the SCSI code, the networking code and the new and improved math-emulator have been totally written by others. So while you can get linux for free, the real reason you'd want to actually *use* (and even pay for it) it is that it's a pretty good unix-like OS. After all, even a free program is no better than what it does or gives you. >I've never used a 386. I'll never use one, unless you put a gun on my head >(then I'll do everything you say. And shoot you in the back at the first > occasion). You are missing out on something. I programmed a 68k machine before getting a PC, and yes, I was a bit worried about the intel architecture. It turned out to be ok, and more importantly: it's the cheapest thing around. A 386 in protected mode is in fact a very pleasant processor, and while it could do with some more registers (at least double the current number), there are no major problems with it. The worst part of a PC-compatible is the BIOS and DOS, and I no longer have to care about them. Even the much maligned ISA bus is pretty good: it may not be technically superior, but it does what a bus is supposed to do very well: hook up hardware. A lot of hardware. It's not even too hateful to program in assembly, and when you program it in C, it looks like any other 32-bit computer. Except for being a lot cheaper than anything else that fast... Not to say I wouldn't like a Mac or an Amiga, but it's certainly a bad idea not to even consider a 386 now that there are good alternatives to MS-DOS around (and no, I'm not necessarily talking linux). Linus ===================== ===================== Newsgroups: comp.os.minix From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: Long filenames Message-ID: <1992Dec23.131313.10139@klaava.Helsinki.FI> Organization: University of Helsinki References: Date: Wed, 23 Dec 1992 13:13:13 GMT Lines: 65 In article chanson@mtlookitthat.chi.il.us (Chris Hanson) writes: >Hi! Can anyone point me to some info (or tell me themselves) on how to >implement long filenames for minix? [I know someone's done it -- one >of the dudes in the 'MINIX vs LINUX' discussion mentioned it.] I'm >thinking that 30 chars or 62 chars shouldn't be that hard (we'd be >keeping a dir_entry at an even multiple of 16 bytes), but I know it'll >involve more than just recompiling the kernel with MAX_NAME changed. The problem shouldn't be so much the kernel as all the binaries you are using: changing the directory structure will break everything that reads directory entries - this includes important binaries like 'ls' (obviously), the shell (for filename globbing, name completion etc), 'make', etc. >Will I need to make new filesystems and move everything to them? Or is >a compatibility hack (such as puting an optional fstype flag or a >different magic number in a device's superblock to tell whether it has >long or standard pathnames) trivial? I'd go for the compatability hack: creating a new filesystem from scratch for the new kernel is simply too painful (as well as making debugging pretty mcuh impossible... much easier to start off with just one partition with the extended setup, and test out all the new binaries on that one first). I'd also suggest you add a "readdir()" system call while you are at it, which checks the magic number and returns the correct type of directory entry. That way binaries compiled to use it will be able to function correctly on both the new and old type of filesystem. There are a couple of alternatives you could do: (a) go for a complete vfs (virtual filesystems) interface. This would make it possible to later add totally different types of filesystems. It's more general, but it's also a lot more coding. This is the approach linux uses, and it gives the possibility to mount msdos etc filesystems transparently. (b) do the long filenames by fooling around with several consecutive minix-type directory entries. Depending on how you do it, you can make old binaries see only th first characters of a extended filename, while new binaries see them all. Besides, this means you won't waste a full 64-char direntry for short files, but instead use several entries only when necessary. The downside is that it's a bit more work in the kernel. The directory entries in (b) could be made to work by using a magic cookie at the end of a filename to mean that the filename continues in the next entry (which has a inode nr of 0 to make old programs ignore it). It could look something like this: file "really_long_name", use '\000\377' as continuation marker: .word inode_number .byte 'really_long_\000\377' /* first 12 chars */ .word 0x0000 /* next entry is a continuation */ .byte 'filename\0' /* rest of the filename */ This can be extended to any filename length, and old programs will see only the first 12 characters, but they should work otherwise. I think somebody implemented something like this. Patches, anybody? Naturally, you'd have to make sure that none of your current filesystems happen to have the '\000\377' sequence at the end of a directory entry, but that should be simple enough. Linus ========================= ========================= Newsgroups: comp.os.minix From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: ACK ANSI Compiler Message-ID: <1993Jan3.115527.11032@klaava.Helsinki.FI> Keywords: ACK, ANSI, compiler Organization: University of Helsinki References: <1i5nm6INN40n@werple.apana.org.au> Date: Sun, 3 Jan 1993 11:55:27 GMT Lines: 34 In article <1i5nm6INN40n@werple.apana.org.au> hock@werple.apana.org.au (Warwick Hockley) writes: > >I think the main point is that most people feel that the 3 compilers should >be unbundled, and the price for each reduced appropriately. The problem with this is probably ACK itself: ACK is a general compiler generation package, so in fact giving three compilers away for the price of one is not such a problem, while selling just one compiler for a third of the price is probably not something ast & co want to do. Remember, it's not really three different compilers, as most of the code is probably the same in all of them. So the $200 can probably be thought of as the price of one compiler, with the others thrown in for free (or something close to that). ast? I also wonder what people really need the new compiler for? On a 68k minix box or a 386, you are probably better off using gcc anyway if you have the memory for it, and if you don't it's probably cheaper (and easier) to buy memory than the compiler. Alternatively you can use the smaller CvW compiler that seemed to work quite well the one time I tested it (but no, I don't think it's ANSI - but unprotoize should probably work with it). For PC's, there is also Bruce Evans' compiler for both 16- and 32-bit code (unprotoize...). The only people I see using the new ANSI compiler extensively would be people with old PC/XT's, and if they can put up with that kind of hardware, thay should certainly be able to put up with an older release of the compiler as well (*). It's not as if you could port many standard unix programs to a 64+64kB machine anyway, so the lack of ANSI shouldn't be that bad an experience: you'd just have to write your programs using K&R. Linus (*) It's a joke guys. Well, mostly. Tongue in cheek, you know. ============================== ============================== Newsgroups: comp.os.minix From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: 68000/i386 C Compiler V4.1 -> V4.2 Patch [Part 1/4] Message-ID: <1993Jan21.140146.8688@klaava.Helsinki.FI> Organization: University of Helsinki References: <1668@ozz.oasis.icl.co.uk> <1705@uitecgw.uitec.ac.jp> <1993Jan21.124103.6725@email.tuwien.ac.at> Date: Thu, 21 Jan 1993 14:01:46 GMT Lines: 19 In article <1993Jan21.124103.6725@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes: >nemossan@uitec.ac.jp (Sakurao NEMOTO) writes: >> I am using C386 version 4.1 on the 486 (33 MHz) machine. I works >>fine. But new Version (4.2 - compiled by 4.1) can not compile itself. >>This new c386 loops forever at compiling src/optimize.c. > >I tried to compile it with gcc 2.2.2, but it wouldn't link. The linker >(from gcc 1.37.1) doesn't print any error messages, but it doesn't >produce an executable either. There must be something magic about >c386 4.2 :-( No - it's probably due to a bug in the linker. I had similar problems when I used the original 1.37 version of gcc+binutils under minix, and solved most of them by compiling gcc-1.40 and a newer version of binutils. I don't remember what the exact reason for the bug was, but it was annoing: 'ld' just died without doing anything (I don't think it even returned an error code to tell you something went wrong). Linus ============================ ============================ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: Minix, Minix, Linux, and SunOS. Keywords: speed Message-ID: <1993Feb12.232505.21737@klaava.Helsinki.FI> Date: 12 Feb 93 23:25:05 GMT References: Organization: University of Helsinki Lines: 54 In article kjb@cs.vu.nl (Kees J. Bot) writes: >Linux is fast, so they claim. This is also what I myself was thinking, >after all, how can a single monolithic kernel with sources that contain >more asm() statements than comments not be fast? :-) I think the problem is more a lack of comments than the number of __asm__ statements.. >Testing time: > >$ cat > x.c >main(argc, argv) char **argv; >{ > write(1, &argv[1][0], 1); > exit(0); >} >$ cc -o x x.c >$ cat > xtest >#!/bin/sh >( > (while :; do ./x x; done & a=$!; sleep 10; kill $a) & > (while :; do ./x y; done & a=$!; sleep 10; kill $a) > sleep 1 > echo >) You don't mention what shell you are using under minix: under linux /bin/sh is automatically the bourne again shell ("and in the blue corner, bash from GNU, weighing in at a whopping 230kB even when stripped and using shared libraries"). If your /bin/sh under minix is the original minix shell ("in the red corner, the original bourne shell, weighing in at 40kB"), your numbers aren't too surprising. >The number of fork+exec's on each system: > > Minix-i86 Minix-i386 Linux SunOS > 673 1219 502 192 > >How? Why? I don't understand it much myself. My mind boggles when I >think about the number of messages Minix-i386 must be producing. Are >Linux shared libraries slowing things down? Half the binaries and half >the speed? :-) No, I doubt it's the shared libraries: they are reasonably efficient. Could you try to compile the minix shell under linux and use that for the testing purposes (alternatively use bash under minix-386: this won't work under normal minix-i86, but should at least give some kind of idea of relative speeds). As to the SunOS performance: hard to say. /bin/sh under SunOS is also more then double the size of the minix shell, and the hardware is different, so the numbers aren't really very meaningful. Linus ========================== ========================== From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: Minix, Minix, Linux, and SunOS. Keywords: speed Message-ID: <1993Feb13.121719.5907@klaava.Helsinki.FI> Date: 13 Feb 93 12:17:19 GMT References: <1993Feb12.232505.21737@klaava.Helsinki.FI> Organization: University of Helsinki Lines: 24 In article kjb@cs.vu.nl (Kees J. Bot) writes: > >The shell I use is /bin/sh, the shell that comes with the system. >That's the shell people are using. The bash shell is as much part of >Linux as those asm() statements. Fair enough - the default linux shell is slow and big when compared to some other shells. >If the system is to be tested, then it must be tested as is. You don't >start by replacing every other utility by some crippled but fast >replacement. True, but in that case the tests should be a bit more meaningful. The only thing your test showed was how fast the shell forks under the systems, and not much else. Lies, damned lies and benchmarks.. Shell fork time does have *some* meaning, but it's usually not noticeable. You might want to try out the BYTE benchmarks - I haven't tested them myself, but they have probably been written to test a more "real" setup (yes, they have a shell benchmark, and I won't mind if you use bash under linux for it). The BYTE benchmarks are probably available for ftp from most bigger sites. Linus ============================ ============================ Newsgroups: comp.os.minix From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: Help with .z files from minnie Message-ID: <1993Apr3.110820.2529@klaava.Helsinki.FI> Organization: University of Helsinki References: Date: Sat, 3 Apr 1993 11:08:20 GMT Lines: 23 In article Mike_Peters@vos.stratus.com (Mike Peters) writes: >I've been t5rying for several hours to get several ".z" files from minnie >"decompressed". I'm using Minix on a Mac, but I've transferred the files >to a pc and tried PKUNZIP on them with no luck. I've also tried zcat under >unix (I know that .z means PC ZIP format, but I hoped the .z was mistyped >and a .Z was really intended). I've also tried several Mac versions of >UnZip without luck. Th GNU world has gone over from the original unix [un]compress to GNU zip (aka gzip), which produces noticeably smaller compressed files and has no problems with patents. Maybe minnie also now uses the gzip format: .z is the standard extension for gzipped archives. You should find sources for gzip at most GNU ftp-sites - it's worth a try. Gzip can also uncompress normal .Z files (the uncompression code isn't patented), and I think it also handles the old 'pack' format (as somebody already pointed out, 'pack' also uses .z, but almost nobody actually uses pack). GNU zip uses the same compression algorithms as pkzip, but has a different header (pkzipped archives contain path information etc, gzipped don't), so pkzip won't uncompress them. Linus ============================ ============================ Newsgroups: comp.os.minix From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: v1.6.25 on i386 Message-ID: <1993Jun1.200514.14817@klaava.Helsinki.FI> Organization: University of Helsinki References: Distribution: comp Date: Tue, 1 Jun 1993 20:05:14 GMT Lines: 96 In article broman@nosc.mil writes: >| prot_init() has set up a gdt compatible with the BIOS interrupt to switch >| modes. The boot monitor has done this already however, but without a proper >| idt. So we reload gdtr, idtr and the segment registers to this better table. >| This is what the BIOS call would have needed: >| gdt pointer in gdt[1] >| ldt pointer in gdt[2] >| new ds in gdt[3] >| new es in gdt[4] >| new ss in gdt[5] >| new cs in gdt[6] >| nothing in gdt[7] (overwritten with BIOS cs) >| ICW2 for master 8259 in bh >| ICW2 for slave 8259 in bl > > lgdt _gdt+BIOS_GDT_SELECTOR > lidt _gdt+BIOS_IDT_SELECTOR Hmm?? I don't know what you are doing, but this looks wrong. 'lgdt' and 'lidt' both take 48-bit pointers as argument, containing the absolute virtual memory address of the table and the extent of the table. This *looks* like you are trying to set up a new GDT/IDT using a selector. I haven't used the BIOS interface, but if I remember correctly, gdt[1] is supposed to contain a memory selector that covers the real GDT, but that does not mean that you can use 'lgdt' on it. Similarly for 'lidt'. You should do something like: lgdt gdt_mem48 lidt idt_mem48 where 'gdt_mem48' and 'idt_mem48' look something like this: gdt_mem48: dw 8*nr_gdt_entries-1 dl vm_offset_of_gdt_table idt_mem48: dw 8*nr_idt_entries-1 dl vm_offset_of_gdt_table And note that "vm_offset_of_XXX_table" is not an offset within the current segment, but actually a 32-bit "flat address" offset = the actual physical address of the table assuming you haven't got paging enabled yet. Additionally, if you want to use the BIOS, I think you'll have to initialize gdt[1] and gdt[2] to be memory segments that cover the gdt and idt tables respectively (ie with the segment base being the offset of the gdt/idt, and the segment limit being at least as long as the gdt/idt table). > jmp far CS_SELECTOR:csinit | ????? >csinit: > mov ax,#DS_SELECTOR This point has several potential problems: - mov ax,#DS_SELECTOR is a 16-bit load in 16-bit mode, but when you change into 32-bit mode the same instruction bitpattern is interpreted as a 32-bit insn. So what happens is that eax is loaded with a 32-bit value, the low 16 bits of which are DS_SELECTOR, and the high 16 bits are from the next instruction.. You have to be *very* careful when trying to create 32-bit code with a 16-bit assembler or vice versa. - are you sure you are jumping to the correct address? Does the old 16-bit segment have the same offset as the new 32-bit segment? In most cases when using 32-bit segments, they are set up to cover the whole 32-bit VM space (or at least a noticeable portion of it), while the old 16-bit segment probably covers only a very small part. And the offsets within those segments to the 'csinit' instruction may well differ. >I infer that the GDT that was just loaded must have been bad, so that >reloading CS causes the crash. But the descriptor tables were created >by C code in protect.c . Is that code designed only for 286 protected mode? While I'd guess that the GDT is bad, you could also have a bad 'csinit' offset (as well as a bad "hanghere" offset) due to possibly different segment bases with the new 32-bit segments? In fact, there are so many things that can go wrong during the switch (and they tend to result in instant reboots), that it's hard to say which of them is the reason.. >The comments found in mpx386.x indicate that the descriptor tables were to be >compatible with the requirements of "the" BIOS. Which BIOS and which >requirements are these? Any 286/386 BIOS has an interface for changing into protected mode: the comments just tell you what the BIOS routines expect to see in the GDT. Actually, using the BIOS interface is probably more pain than gain, and unless the rest of the bootup sequence wants to use it, I'd suggest doing it by hand (but that's not exactly easy either), as it gives you more control of what to set into the segment descriptors. Besides, it's more interesting that way :-). But you probably *will* need a good book in order to understand the "somewhat non-intuitive" 386 segmentation setup. Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix,comp.os.386bsd.misc,comp.os.386bsd.questions,comp.os.linux,alt.uu.comp.os.linux.questions Subject: Re: Choosing a Unix like OS for a pc Date: 20 Jun 1993 13:48:25 +0300 Organization: University of Helsinki Lines: 21 Message-ID: <201f9p$kkv@klaava.Helsinki.FI> References: <1993Jun19.125224.17510@colorado.edu> NNTP-Posting-Host: klaava.helsinki.fi In article jimr@world.std.com (James A Robinson) writes: > >As I understand it Linux has more features then Minix and takes up >less space then 386bsd. Apparently the TCP/IP of BSD is more stable >then Linux, but that may have already changed, as I only have an old >FAQ. In any case Linux is one of the hottest unix look-alikes around, >since Linux seems to have the knack of making the kernel look like it >was running on a RISC rather then an 80486. :-) All the tools run >very fast, and I can compile the kernel in about 18 minutes, which in >my opinion is darn fast for a 486sx 25MHz. To give minix some credit: Bruce Evans told me he was able to recompile the kernel in less than one minute if I remember correctly. Of course, he has a reasonably fast machine and minix sources are smaller, but the main time-saver is that the minix (and coherent) C-compilers are much faster than gcc... Not that I would trade the compilers, but if you are looking for speed of compilation, minix and coherent both do it faster than either linux or 386bsd (at the expense of features and code quality). Linus ============================= ============================= From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: Choosing a Unix like OS for a pc Date: 29 Jun 1993 21:56:22 +0300 Organization: University of Helsinki Lines: 29 Message-ID: <20q38m$bj1@klaava.Helsinki.FI> References: <1993Jun29.182612.23802@udel.edu> NNTP-Posting-Host: klaava.helsinki.fi In article <1993Jun29.182612.23802@udel.edu> Steve_Kilbane@gec-epl.co.uk writes: >In article <9306291722.AA17256@cuthbert.bashstreet> Chris Maeda, Grad Student and RetroGrouch writes: > >>What a breakthrough! If you want your kernel to compile twice as >>fast, use a compiler that's twice as dumb or leave out half the >>functionality. You guys should write a paper for usenix. > >I hope this should have a smilie after it... the point is that Oberon goes >for a *minimalist* system, not a *non-functional* system. The functionality >is there, but you've got a smaller, cleaner set of primitives. Contrast >bash with rc for a rough idea of this concept - it's what UNIX used to be >synonymous with, instead of with a bloated morass of ageing code ... It's also a question of resource-handling: some systems that are smaller and simpler will work a lot better on a small machine, even though "we real men" laugh and ridicule them. I tried to stress-test the linux mm routines the other day by re-compiling the kernel on a machine with only 2MB of memory, and I simply gave up after 5 hours when it hadn't even made it half-way... gcc was simply swapping itself to death, and 'time' reported that of the 5 hours passed, only about 6 minutes had been used for any real user-level work. I'll be the first one to say that I prefer linux over minix, but even when linux works, it does need more resources to run (not so much due to kernel bloat as to memory requirements of the standard programs, although the kernel is bigger too). The same is usually true of other similar comparisons. Linus ============================= ============================= From: torvalds@cc.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: Minix + Linux... Date: 26 Jul 1994 14:29:18 +0300 Organization: University of Helsinki Lines: 16 Message-ID: <312s2e$a7t@klaava.Helsinki.FI> References: NNTP-Posting-Host: klaava.helsinki.fi Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article , George Shin wrote: > >2. Since Linux can work with Minix filesystem formats, can i prepare the > Minix partition and make the file system before installing Minix > to my hard disk? When i was installing Linux, i set aside 50MB of > partition for Minix... If you make the partition from within linux, make sure (a) to use 14-character filenames ("-n14" for mkfs.minix, if I remember correctly - long time since I wrote it :-) and (b) don't use symbolic links which are not supported in standard minix. (I think the minix symlink extension patches uses the same symlink format linux does, but I don't know) Linus ============================= ============================= From: torvalds@cc.Helsinki.FI (Linus Torvalds) Newsgroups: comp.os.minix Subject: Re: Minix + Linux, File Systems Date: 29 Jul 1994 10:30:24 +0300 Organization: University of Helsinki Lines: 29 Message-ID: <31ab6g$k7r@klaava.Helsinki.FI> References: <317uls$l77@louie.udel.edu> NNTP-Posting-Host: klaava.helsinki.fi Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <317uls$l77@louie.udel.edu>, Georg Wagner wrote: >>Also note that Minix and Linux have a minor(*) difference in how they >>remove a file: > >A word of warning however! Linux and Minixfs are still incompatible in some >ways. The bitmap formats are currently incompatible! This means you shouldn't >write to Minixfs partitions with Linux or vice versa before running the native >fsck. [ big-endian / little-endian ] Note that this is not true for the i386 version, at least. But it might be true for the 68k version of linux, although I haven't looked into it. However, if I remember correctly, there is one small incompatibility even on the i386 version - I think the minix bitmaps wrap around to use bit #0 as the highest bit under some very rare circumstances (when the bitmap is exactly a multiple of the blocksize). They don't wrap around under linux (bad idea in the first place). Note that if you use the linux mkfs.minix, I added some silly stuff to change the size of the bitmaps so that this one-bit-difference would never occur (and if you use minix mkmf you will also have to work very hard to find the right parameters to make it happen). It's a long time since I wrote that stuff, and I no longer have minix to check it, so the above may be a bit off. Nobody has ever even noticed the differences, I think (well, bde did, but he's not really human). Linus =========================== =========================== From: torvalds@cc.Helsinki.FI (Linus Torvalds) Subject: Re: FS size supported in 1.7 Date: 1995/12/24 Message-ID: <4bjd8l$hpu@klaava.helsinki.fi>#1/1 sender: torvalds@cc.helsinki.fi references: content-type: text/plain; charset=ISO-8859-1 organization: University of Helsinki mime-version: 1.0 newsgroups: comp.os.minix In article , Kees J Bot wrote: > >>BTW: How does Minix (old) FS acces more than 64M? I saw the BLOCKS_SIZE >>defined as 1024 Bytes. > >The disk drivers use a 32-bit block number even under Minix 1.5. So the >size of the disk or a partition is limited to 4 G as far as the drivers >are concerned. Actually, in this day of multi-GB harddisks, it might be worth pointing out that 32-bit block numbers are good for 4TB worth of disk-space, as long as you do block-addressing (assuming a 1kB block size here). This is how the linux ext2fs is able to handle large (where large means ">> 4GB", not "> 256MB" ;-) filesystems even though all block numbers are 32 bit. We have a 20GB filesystem on our university linux NFS server, and you can even keep fsck times down by (a) using a UPS and (b) having a reasonably clever fsck. > FS further limits this to 2 G because file positions are >signed (off_t). A file size limit of 2GB is not nearly as debilitating as a filesystem limit of 2GB. Generally you need larger files only for large databases (famous last words: I'm sure somebody will shoot me down for this), and lots of databases want to do their own "filesystem" anyway (ie write to the raw disk device). > A file system is further limited by the maximum number >of 32 zone bit maps. (One bit map can see 8 K zones = 8 M bytes for a >1 kb zone size.) Sure, that can be a problem. I haven't taken a look at the new minix filesystem, but this can generally be handled by having a lot of zone bitmaps, and not having them all in memory at the same time. That does make the filesystem code more complex, though. Linus ========================= ========================= From: torvalds@cc.helsinki.fi (Linus Torvalds) Subject: Re: Minix Source Date: 1996/03/27 Message-ID: <4jb4m1$dc0@kruuna.helsinki.fi>#1/1 references: <31573026.7516@rcsn.nb.ca> <31a7cc$ffe.1e0@news.hampshire.edu> content-type: text/plain; charset=ISO-8859-1 organization: University of Helsinki mime-version: 1.0 newsgroups: comp.os.minix In article <31a7cc$ffe.1e0@news.hampshire.edu>, Albert S Woodhull wrote: >On Mon, 25 Mar 1996 15:45:42 -0800 Geoffrey Hamilton >(hamiltong@rcsn.nb.ca) wrote in comp.os.minix: > >: I've been trying to read the minix source code from ftp.cs.vu.nl. I've >: followed the actions to a "tee" and when I attempt to mount /dev/fd0 (the >: 1.44 Mb drive it's in) specifying type minix (I'm using Linux) it gives >: me a "wrong fs or bad superblock" error. What am I doing wrong..? > >Linux supports an old version of the Minix file system, but a new (V2) >file system was introduced some time ago, and Linux doesn't know how >to handle it. (At least my fairly old Linux 1.0.8 kernel doesn't, it >may be supported in newer versions). It is indeed supported in the newer versions, but I haven't tested this myself (the code is there, and it obviously worked for gertjan@cs.vu.nl, but there hasn't been any feedback on it that I have seen). However, you do have to get a fairly recent linux kernel in order to get this functionality - and I don't think any of the CD-ROM's have anything that recent pre-compiled so you have to do that yourself (obviously, if you're interested in the minix sources, you are not likely to be nervous about compiling your own linux kernel). Linus =========================== ===========================